As an aside, I used the above compiler version to launch verif/regress/coremark.sh and got total ticks = 229114.

Hi @isa084, please do not introduce multiple topics into a single issue or pull-request. This PR is about the gcc 16.1 baremetal toolchain. If you'd like to ask a question about coremark please do so in a new/different Issue. If GitHub is not a good fit for the discussion, consider posting a question to the CVA6 channel on MatterMost.

@MikeOpenHWGroup Sorry about that !

I will open another issue or post it on the CVA6 channel on Mattermost

Hi @isa084
We need to install GCC 16 on Thales CI runners to test the PR.
I will let you know when it is done!

Hi @isa084,

When we upgraded the CVA6 GCC baseline to version 15, the move (and the asociated effort) was motivated by a notable improvement in benchmark perfomance, especially on CoreMark. Does GCC 16 bring any significant benefits in target feature support /perf / code size compared to GCC 15?

@zchamski from my past experience with ARM/RISC-V cores, there is no guarantee that merely upgrading the compiler will lead to performance improvements. I am in interested in investigating this further, once the above PR is accepted.

Hello @isa084
Lot of different tools are needed to support CVA6 functionalities: Spike, compilers, Verilator, VCS, Questa, Synthesis tool, Power tools, FPGA tools, ... Upgrading tool requests effort. We will upgrade GCC in the case there is an interest.

To demonstrate the performance improvements, coremark job can be used. With GCC15, we are currently at 5 Coremark/MHz.

With GCC15, we are currently at 5 Coremark/MHz.

FWIW, Gemini says, "For modern 32-bit microcontrollers, 3.0 to 5.0 CoreMark/MHz is excellent."

Hi @JeanRochCoulon . I am sorry for the trouble as I did not anticipate the overhead.

My reason for submitting the patch :

1. In one of my internal CVA6 forks, I am building support for new ISEs that are only compatible with the latest versions of spike, proxy kernel, and RISC-V GNU toolchain. Since we resolved this issue by upgrading to gcc 16.1 , I thought it best to submit the patch back to upstream.
2. New gcc updates generally open the path to exploration of new performance optimizations available in newer gcc versions. These improvements are not guaranteed with every version upgrade, and take time to work out.

As I now understand, upgrading the gcc toolchain version is non-trivial, especially with respect to various dependencies. If you think the effort outweighs the benefit at this point, then this PR may be closed without merging. It can be reopened later, if/when the support becomes relevant.

Independently, I will continue looking into performance improvements with newer gcc versions (outside the scope of this PR), to produce useful evidence. Let me know if this is helpful.

Thanks you for your understanding. If you are agree, as soon as you see an advantage into upgrading the GCC version (by an improvement of Coremark for example), we will upgrade the GCC Version. In the mean time, you can close this PR and reopen it when you think it is worth doing it. Thanks again for your understanding.